Customization Policies Need more than Rule Objects

In this paper we analyze the process of mapping business policies into object-oriented software structures. We stress that separation of concerns is a key strategy for obtaining high quality and evolvable implementations. In particular, we show that a naive mapping of business policies into object rules may result in a bad design compromising the overall software stability. We first present our work in the context of customizable of e-commerce applications, and briefly explain why customization functionality should be dealt by separating concerns. We next present our approach for combining object rules with other object-oriented design structures; we show that these modular software constructs allow seamless evolution and maintenance. 1-Introduction and Related Work Customization has become a very important issue in e-commerce applications. Adapting this kind of applications may mean building different interfaces, (customized to a particular appliance) providing personalized navigation paths, offering different pricing policies, customized checkout procedures, etc. Not only we need to design an application model, but also to design and apply different business policies, manage information about the user and his profile, etc. Furthermore, as we must also cope with constant changes of these policies, the design should be modular enough to make evolution seamless. So far, little attention has been paid to the modeling and design process of this kind of software. Only recently, some authors have proposed reference design architectures for personalized or customized software [Koch 02, Kappel 01]. These approaches emphasize a clear separation of concerns among the application objects, the customization rules and the user profile. They follow a widely used strategy for modeling business rules as first-class objects, thus decoupling them from the application-specific code [CommonRules 02, RuleML 02]. The user profile is also represented as a set of objects addressing different user preferences (language, location, etc). User profiles are often described as aggregations of objects whose attributes contain plain information such as “English”, “Los Angeles” and the like. Customization and other business rules use this information by checking these attributes and performing corresponding actions. The main thesis in this paper is that existing approaches fail to provide a good and modular platform for implementing customization policies. While the rules paradigm works fine with some kinds of business policies, it may end with a large and flat set of similar rules thus complicating maintenance. Moreover, treating information in the user profile as low-level objects (such as strings or numbers) neglect polymorphism and, as a consequence, makes this kind of software evolution a nightmare. We present an original approach for complementing customization rules with more general customizer objects for building maintainable software. The structure of the rest of this paper is as follows: We first discuss existing architectural constructs for decoupling concerns in customizable software and introduce an example to illustrate our ideas; we next show that a wise application of objects polymorphism allows us to build composite customizer objects combining different customization policies. Though this paper is based on our previous experience with the (OOHDM) Method [Schwabe 98], the underlying ideas can be used in a straightforward way with other object-oriented approaches. 2-Customization in Business Applications While building customizable object-oriented software, it is useful to understand what aspects of an application can be customized. For some years we have mined recurrent patterns in e-commerce applications, focusing on one of the most usual customization types: personalization [Rossi 01]. These (coarse grained) patterns allow us to focus on what can be customized before addressing which concerns are involved in the customization design process. Summarizing we can customize: · the algorithms and processes described in the application model (e.g. different recommendation strategies, pricing policies or check-out processes for different users, etc) · the contents and structure of object’s interfaces and the link topology in the resulting interface (e.g., building customized home pages such as in my.yahoo.com) · the look and feel of the interface and the interaction styles (for example according to the interface artifact, e.g. a cellular phone, a PDA, etc). Most approaches for mapping business rules into object structures have focused on the first kind of customization, i.e. emphasizing on process customization according to different object’s values that reflect business states [CommonRules 02]. The main rationale for separating rules from application code is to achieve a better degree of concern separation, thus eliminating spurious if clauses inside object’s methods. However when we need to implement customization policies that deal with a user profile, rules are not always the best solution 3-Reference Architectures for Customizable Software Existing approaches for building customizable software clearly separate the most important design concerns related with customization, namely the application model, the customization rules and the user profile. Each module can be considered itself a simple micro-architectural component; the interaction between these components should follow well known patterns in order to keep the software manageable. In order to make this discussion concrete, we introduce a simple example here. Suppose an electronic store that sells products to customers. When he decides to buy, the check-out process generates an order containing products, paying mechanism, shipping address and price and delivering options. Each customer has an account containing his buying history. While variations in the domain model such as adding new products or paying mechanisms can be solved by sub-classing and composing objects, if we want to introduce some personalization capabilities, we face a new problem: mixing customization code with application logic. Following the previous idea we will have at least two other software modules for dealing with personalization: · The user profile: that contains information about the customer’s interests; it will need to interact with some application’s objects such as the Customer and Account objects (by the way one may argue that it is debatable whether these classes should be part of the user profile). When software adaptation involves other aspects (such as date or time) a separated context model is also necessary. · The rule model: that encapsulates different kinds of rules, for example for calculating a personalized price, etc; when dealing with event/condition/action rules, separated event objects will be used. However, existing approaches fail to address two key aspects for building this kind of software: how to seamlessly connect application code with customization components and the process of rules engineering and design. We have shown an approach for solving the first problem in [Cappi 01] by associating customizer objects to each customizable behavior. When an application object receives a message whose answer must be customized, a customizer object is in fact activated; it interacts with the original object, the user profile and the context to generate the correct answer. We will not elaborate the activation of customizer objects in this paper but will focus instead on the engineering of customization policies, which is described in the